(12) INTERNATIONAL AFPUCATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date 
27 September 2001 (27.09.2001) 




PCT 



111 



(10) International Publication Number 

wo 01/71499 Al 



(51) International Patent Classification^: G06F 1 1/30, 
15/173 

(21) International Application Number: PCT/USO 1/07629 

(22) Intematioaal Filing Date: 9 March 2001 (09.03.2001) 



(25) Filing Language: 



(26) Publication Language: 



English 



English 



(30) Priority Data: 

60/190,326 
09/766343 



16 March 2000 (16,03 JtOOO) US 
19 January 2001 (19.01.2001) US 



(71) AppUcant: COUNTERPANE INTERNET SECURITY, 
INC. [US/US]; 3031 Tlsch Way, 100 Plaza East, San Jose, 
CA 95128 (US). 



(72) Inventors: SCHNEIER, Bruce; 101 East Minnehaha 
Parkway, Minneapolis, MN 55419 (US). GROSS, An- 
drew, H.; 1055 Coleman Road, #2309. San Jose, CA 
95123 (US), CALLAS, Jonathan, D.; 1781 Wema Way. 
San Jose, CA 95124 (US). 

(74) Agents: LAURIE, Ronald, S. et al.; Skadden, Arps, Slate. 
Meagher & Horn LLP. 525 University Avenue, Palo Alto. 
CA 94301 (US). 

(81) Designated States (national): AE, AG. AL, AM. AT, AU. 
AZ. BA. BB, EG. BR. BY, BZ. CA. CH, CN. CO, CR, CU. 
CZ. DE. DK, DM, DZ. EE. ES. R, GB, GD, GE. GH. GM, 
HR, HU, ID. IL. IN, IS. JP, KE, KG. KP, KR. KZ. LC. LK, 
LR. LS. LT. LU. LY, MA, MD, MG. MK, MN, MW, MX, 
MZ. NO, NZ. PL. FT, RO. RU. SD. SE, SG, SI. SK, SL, 
TJ. TM, TR, TT, TZ. UA. UG, UZ. VN, YU, ZA, ZW. 

(84) Designated States (regional)-. ARIPO patent (GH. GM, 
KE, LS. MW, MZ, SD, SL, SZ. TZ. UG, ZW), Eurasian 

[Continued on next page] 



(54) Title: METHOD AND SYSTEM FOR DYNAMIC NETWORK INTRUSION MONITORING, DETECTION AND 
RESPONSE 



Architectural Diagram 



On 
On 



O 



Customer 
Site 



Decoys 4i 
I Hottypott 

(1030) 



Cistoffl 
Af cuts (1040) 




MOO 



DaliCoUfCliM 
AFmcriDg 

Sjmaooo) 



Cofflourdal 
AfMls(1020) 



nrcwsUs A 
tatmioa 
Oeteccios 

(1010) 



Ntw«ric(IOOO) 



see 

Operations 



Opcntiai 
Fnct4orts 
(WO) 



Repovt 

GcOCTitilM 

«040) 



Cattwty 

Syim 
(4000) 



(90M) 



SOCRATES: 
Problem A 
Expcrtist 

Syyttn (6000) 




(57) Abstract: A probe (2000) 
monitors sensors attached to 
the network for evidence of 
unauthorized intrusions. Such 
sensors include: firewalls and 
intrusion detection systems (1010), 
commercial sensors and agents 
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probe (2000) into messages 
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operating procedures (6030). Such 
operating procedures can include, 
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respond to certain types of attacks. 
The SOC (6000) can generate 
reports (6040) based on the activity 
of the network. All suspicious 
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METHOD AND SYSTEM FOR DYNAMIC NETWORK INTRUSION 
MONITORING, DETECTION AND RESPONSE 

FIELD OF THE INVENTION 

This invention relates generally to network security and, more specifically, to 
methods and systems for dynamic network intrusion monitoring, detection and response. 

BACKGROUND OF THE INVENTION 

Most computer and network security products fociis on prevention. Firewalls 
prevent unauthorized traffic from entering a company's internal network; authentication 
mechanisms prevent unauthorized persons from logging on to a company's computers; and 
encryption prevents unauthorized piersons from reading files. But because such products 
cannot be relied upon to work perfectly, and because security bugs may exist in other 
software or hardware, complete network security also requires monitoring, detection and 
response in the event of a breach. 

An effective monitoring, detection and response system should be designed not to 
replace a customer's system administrators but to augment their abilities. System adminis- 
trators normally do not have the time or ability to read through large amounts of constantly 
updated audit information, looking for attacks on their systems. They also do not have the 
time to continuously monitor hacker activities, looking out for new tactics, tools and 
trends. Finally, they do not have the time to become experts on every kind of intrusion 
and to maintain that expertise. 

A monitoring, detection and response system that employs human intelligence, 
uses trained personnel in the loop, and takes advantage of security intelligence and other 
knowledge databases can provide customer system administrators the advice and coaching 
they need, when they need it, to help them repel attacks and maintain network integrity 
and uptime. While automatic defenses may work against automated attacks, they are at a 
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disadvantage against an intelligent attack, against which is needed the kind of intelligent 
defense offered by the present invention. 

SUMMARY OF THE INVENTION 

The present invention offers methods and systems for dynamic network intrusion 
monitoring, detection and response. In an exemplary implementation, these methods and 
systems may be used to deploy and provide a managed security monitoring service (the 
"MSM service") that monitors a customer's network activity using a probe or "sentry" 
system, collects status data from monitored components, filters or otherwise analyzes the 
collected data for activity possibly implicatmg security concerns, alerts and transmits 
information about such activity to trained security analysts working at secure operations 
centers ("SOCs"), and then guides the security analysts and customer through an appropri- 
ate response (with appropriate follow-up, if necessary). 

The MSM service is not intended to replace but to supplement, and thereby render 
more effective, a customer's existing preventive security products. Such products, which 
can include firewalls, servers, routers, intrusion detection systems, and other security 
products, can generate millions of lines of audit information each day. Buried in all that 
information may be the footpriiits of ongoing network attacks or intrusions. The MSM 
service can help filter and analyze all of that audit information in effectively real time to 
detect such attacks or intrusions. 

Once a possible attack or intrusion (referred to more generally as an "incident" or 
"event") is detected, its characteristics and particulars may then be examined and analyzed 
by trained security analysts continuously monitoring the customer's network to further 
understand the incident and eliminate false positives, hi analyzing the incident, security 
analysts can draw upon information and knowledge contained in a variety of databases, 
including but not limited to security intelligence databases containing information about 
the characteristics of various hacker techniques and tools and known vulnerabilities in 
various operating systems and commercial software products and hardware devices. If 
necessary, security analysts can escalate the handling of the incident according to a variety 
of predetermined escalation procedures to stop the attack and shut down the vulnerability 
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before the attacker does any damage. In effect, the MSM service acts as a defensive shield 
for a customer's network. 

In an exemplary embodiment, the MSM service may allow for customization and 
complex data analysis. For example, the service may be customized, either dynamically or 
5 off-line, to accommodate network-specific needs and to reflect feedback received about 
the demonstrated efficacy of a real world response to an actual event. Furthermore, data 
filtering and analysis can include cross-product analysis, which allows the probe/sentry 
system to correlate and recognize such multiple sensor readings as reflecting the same 
happening. Such features ensure that the invefntion is cs^able of the rapid refinement 
1 0 necessary to combat network attacks. 

The specific components of an exemplary implementation of the MSM service 
would likely include the following: 

A. Security Analysts: Security analysts are personnel speciaUzing in the analysis 
of network attacks. In an exemplary embodiment, such analysts would perform only such 

15 analysis and thus develop the most extensive knowledge in the field. In addition, given 
their access to sensitive customer information, security analysts would preferably pass 
background checks and be bonded to provide extra assurance for customers of the MSM 
service. 

B. Security Intelligence: In an exemplary implementation, the expertise, knowl- 
20 edge and capabilities of MSM service security analysts can be supplemented by a variety 

of knowledge databases containing detailed information helpful for investigating, evaluat- 
ing and responding to incidents. Security intelligence databases can contain information 
about, among other things, the characteristics of various network hardware and software 
products, known vulnerabilities of such products, the use and characteristics of various 
25 hacker tools, and known effective and ineffective responses to various kinds of attacks. 
Such databases could be continually updated by the MSM service by, for example, 
monitoring hacker forums, reviewing security analysts* incident reports, and evaluating 
customer audit data for new attack footprints. 

C. Secure Operations Centers f "SOCs"V MSM service security analysts would 
30 preferably work in secure operations centers. To ensure the security of their customer 

networks, the SOCs should be connected to these networks preferably through 
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cryptographically secured tunnels (also called "pipes" or "pathways"). Furthennore, the 
SOCs should provide no other interconnection with these pipes and should themselves be 
physically hardened against attack. Although single SOC operation is possible, multiple, 
geographically separated SOCs can be used to provide redundancy and additional capacity 
for increased traffic or failure of one of the SOCs. 

D. Probe/Sentry System: The invention generally incorporates one or more 
probe/sentry systems that may collect data from a variety of software products and 
hardware to which they are attached. Such systems are preferably lociated within the 
customer's firewall and may collect such data fix)m essentially any product or device that 
can be configured to provide data to a remote device. Once the probe/sentry system 
collects the data, it then filters or otherwise analyzes such data and then transmits notewor- 
thy information, preferably via a secure connection, in the form of "sentry messages" to a 
gateway system (described below in section E) at a SOC. Preferably, the system can 
perform preliminary analysis of the resulting data, either by simple filtering, 
crossHJOrrelation, cross-analysis, or other means to reduce the immense volume of raw 
data into core information worthy of further analysis. 

E. Gateway System: The invention may also include one or more gateway 
systems that serve a "gatekeeper" fraction in linking the probe/sentry systems to a SOC. 
Two possible fimctions of such a gateway system are (1) to reformat, add, or delete 
information to incoming messages firom the probe/sentry systems ("sentry messages") to 
ensure maximum utility of the output "gateway messages" and (2) to allow mutual "pulse 
monitoring" by the gateway and probe systems of their counterparts to ensure that each 
system is continuously operational. This latter fimction might allow probe/sentry systems 
to initiate contact with a redimdant gateway system to ensure that each probe/sentiy 
system is continuously connected to a SOC at all times. 

F. The "SOCRATES" Problem and Expertise Management System: In an 
exemplary embodiment, security analysts at a SOC work in concert with the "SOCRA- 
TES"* problem and expertise management system to categorize, prioritize, investigate and 
respond to customer incidents or "problems." The SOCRATES system, among other 

* . "SOCRATES" is an acronym standing for Secure Operations Center 
Responsive Analyst Technical Expertise System. 
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things, collects and foiinats gateway messages into "problem tickets" (each of which 
represents a discrete security-related event or incident of possible intrusive activity 
happening on a customer's network), associates with each such ticket information useful 
for problem investigation, resolution and response, presents such tickets to security 
analysts for handling, and generally serves as a repository of useful information and 
procedures. Preferably, in the process of orchestrating the management of problem tickets, 
the SOCRATES system continuously augments problem-solving tools such as tables 
which tie symptoms to technology, symptoms to diagnosis, or vulnerability to diagnosis. 
This continuous improvement allows the invention to take full advantage of specialized 
nature of the monitoring system. 

BRIEF DESCRIPTION OF THE FIGURES AND APPENDICES 

FIG. 1 is an overview of the system architecture of an exemplary embodiment of 
the present invention. 

FIG. 2 is a system overview of an exemplary embodiment of a probe/sentry system 
in an exemplary embodiment of the present invention. 

FIG. 3 is a system overview of an exemplary embodiment of a gateway system in 
an exemplary embodiment of the present invention. 

FIG. 4 is a system overview of an exemplary ehibodiment of a problem and 
expertise management system in an exemplary embodiment of the present invention. 

FIG. 5 is a flowchart illustrating an exemplary implementation of incident handling 
by a security analyst in an exemplary embodiment of the present invention. 

FIG. 6 is a diagram illustrating exemplary escalation paths for various types of 
escalation in an exemplary embodiment of the present invention. 

FIG. 7 is a flowchart illustrating an exemplary implementation of a customer call 
handling procedure for a customer call arising from an existing problem ticket, in an 
exemplary embodiment of the present invention. 

FIG. 8 is a flowchart illustrating an exemplary implementation of a customer call 
handling procedure for a customer cold call due to something the customer found on the 
customer's own network, in an exemplary embodiment of the present invention. 



wo 01/71499 PCT/USOl/07629 

6 

FIG. 9 is a flowchart illustrating an exemplary implementation of a problem 
workflow in an exemplary embodiment of the present invention. 

Appendix A provides specific details pertaining to an exemplary system for the 
transfer of infonnation between customer networks and gateway systems (the "Pipes 
Protocol"). 

Appendix B provides possible configuration details for an exemplary embodiment 
of the problem and expertise management system. 

Appendix C provides details regarding the scope and structuring of information 
that might be retained and utilized by an exemplary embodiment of the problem and 
expertise management system. 

DETAILED DESCRIPTION OF THE INVENTION 

FIG. 1 is a overview of the systems in an MSM service exemplary implementation 
of the present invention. FIG. 1 is divided into two portions, components and systems that 
operate on the customer site (that is, within the customer's firevyall) and components and 
systems that operate within the SOC (that is, witiiin the SOC firewall). A single SOC can 
monitor and service multiple customer sites, and a single customer site can be monitored 
by multiple probe/sentry systems. For ease in understanding, this discussion assumes a 
single SOC servicing a single customer site being monitored by a single probe/sentry 
system. 

Probe/sentry system 2000, which can be implemented in software or hardware or a 
combination of software and hardware, monitors sensors attached to customer network 
1000 for evidence of potential security-related events happening on networic 1000. Such 
sensors can include firewalls and intrusion detection systems 1010, commercially avail- 
able sensors and agents 1020, decoys and honeypots 1030 (monitored devices or programs 
specifically and solely designed to attract the attention of, and thereby expose, a would-be 
intruder), and custom sensors and agents 1040. More generally, probe/sentry system 2000 
can monitor and collect information from any network component (whether software or 
hardware or a combination of both) that can be configured to send or provide to it status 



wo 01/71499 PCT/USOl/07629 

7 

data (including audit log data and other audit infonnation) concerning the status of 
network 1000 and its components. 

Both sensors and agents can monitor network components. However, while 
typically a sensor passively receives status data and audit information from network 
components set up to send such information to the sensor, an agent is designed to actively 
seek such infonnation from the components it is monitoring. Sensors may include 
scaiming engines, syslog data providers (including devices such as routers and firewalls), 
Simple Mail Transfer Protocol ("SMTP") sensors, Simple Network Management Protocol 
("SNMP") sensors and SNMP traps. SNMP sensors generally require polling and may 
require additional software provided by the MSM service, whereas SNMP traps generally 
send data directly, without prompting. Sensors and agents may be customized for the 
particular needs of a customer's network, for example, to provide information not provided 
by those sensors and agents that are conmiercially available. Commercial security 
products and devices that may be attached to a customer's network include the following 
manufacturers and products: NFR, ISS, NETA (McAfee, Gauntlet, Cybercop), NetRanger 
(Cisco), Dragon, Checkpoint, Lucidian, Symantec, Cisco, Nortel, 3Com, Lucent, 
Livingston, Tripwire and Centrax. 

Probe/sentry system 2000 collects and filters (positively and/or negatively) or 
otherwise analyzes the constantly updated status data it receives from sensors, using a set 
of rules and/or filters looking for evidence or "footprints" of unauthorized intrusions. The 
collected status data can either remain in the customer's hands or be provided to MSM 
service personnel for further analysis (e.g., cross-customer analysis). The software and 
filters of probe/sentry system 2000, in a preferred embodiment, may be adaptive or, 
alternatively, may be manually updated offline or dynamically (that is, during actual 
operation). In a preferred embodiment, such updates can be sent from the SOC to the 
probe/sentry system and signed, verified and then securely installed. In a preferred 
embodiment, probe/sentry system 2000 can also manage updates to other customer 
software, including antivirus signature files and software, firewall software, and router 
software. Such updates can be controlled by communications and resource coordinator 
2060 within probe/sentry system 2000. 
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Noteworthy data possibly indicating an unauthorized intrusion or other secu- 
rity-related event are formatted by probe/sentry system 2000 into "sentry messages," 
which are then sent via "Pipes" communications system 3000 (referred to hereafter as 
"Pipes 3000") to gateway system 4000 at the SOC. 

In a preferred embodiment. Pipes 3000 provides an encrypted, secure communica- 
tions path and message protocol for messages sent back and forth between probe/sentry 
system 2000 at the customer site and gateway system 4000 at the SOC. The Pipes 
protocol preferably runs inside a Transport Layer Security ("TLS") session or other 
protected path. Either side can send individual messages containing identification 
information and a payload. Messages, in an exemplary embodiment, can be limited to a 
maximum size of, for example, 64k bytes in length. Larger messages could be sent 
fi-agmented across several messages with acknowledgments. Appendix A provides 
specific technical information pertaining to an exemplary Pipes protocol. 

Pipes 3000 may be used to manage bandwidth consiunption at both ends and can 
be used by the SOC to send software updates to probe/sentry system 2000. Message flow 
through Pipes 3000 can be controlled by means of (i) a client program or process running 
on the probe/sentry end to service queues of incoming messages fi'om and outgoing 
messages to the SOC; and (ii) a server program or process running on the gateway end to 
service queues of incoming messages from and outgoing messages to various probe/sentry 
systems. In an exemplary embodiment, a public key infixistructure ("PKI") scheme using 
QpenSSL-based TLS and Digital Signature Standard ("DSS") certificates can be used to 
authenticate both ends of Pipes 3000 as well as the messages being passed back and forth. 
For example, web delivery of customer network status reports, as well as certain customer 
requests, might be authenticated. In addition, Pipes 3000 can include a bootstrap protocol 
to support its initial installation as well as a recovery protocol to support recovery in the 
event of a probe/sentry or gateway failure. 

An exemplary architecture for Pipes 3000 is as follows. A process on the 
probe/sentry runs as root. This process can keep its control information in a certain 
directory. To send a message, another process on the probe/sentry can send this root 
process a Transmission Control Protocol ("TCP") connection on, for example, 127.0.0.1 
port XYZ and emit a message in "Pipes User Message Format." A response may then be 
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sent back to the Pipes client indicating success, failure, or enqueued. The Pipes client can 
maintain a context for the SOC to which it is currently connected. Possible states include 
"connected" and "attempting to connect." Preferably, the Pipes client should always be 
connected to a SOC (or attempting to connect). The Pipes client also preferably runs a 
loop with selects and sleeps such that it processes input from its SOC and from clients on 
the local machine. The root process running on the probe/sentry can use, for example, port 
443 to behave as a normal TLS (SSL) client and can also listen on port 468 ("photuris"). 
The root process should be started before everything else, so the probe/sentry filtering 
subsystem can talk to it. A process running on the gateway should listen to port 443. 
When it gets a call, it should foric a child process that handles the probe/sentry. There 
should therefore be one process per probe/sentry, although each gateway might be 
associated with a few hundred or more probe/sentries. There should also be a port 468 
connection to the probe/sentry system communications and resource coordinator. 

Pipes 3000 may be implemented using a variety of different mechanisms, depend- 
ing on the customer's needs. One possible mechanism uses a secure Internet connection 
implemented using, for example, a Virtual Private Network ("VPN"), SSL/TLS, Secure 
Shell ("SSH"), IP Security ("IPsec") or other techniques. Other alternatives include using 
leased lines, dial-up hnes, or even wireless point-to-point systems. The most demanding 
customer might employ all of these, with multiple cellular coimections (each with a 
different provider) so that a fai toe of one cellular provider would not result in missing an 
alert. In one embodiment, Internet connections could be used predominantly, with slower, 
alternative connections as backup in case of failure, although some customers might want 
high priority alerts to be delivered over a cellular link so as not to reveal information to an 
attacker. 

Additional security considerations for Pipes 3000 include the following: 

• use of TLS 

• authentication handles based on, for example, signatures 
PKI bootstrap 

• threat model 

• losses of connections to Sentry or Gateway 

• Sentry or Gateway integrity compromises 
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Additional possible alternative implementations of Pipes 3000 include the 
following: 

• use of openssl s server and sjclient as skeletons 

• use of dss certificates 

• use of redfish in place of triple data encryption standard ("TDES") as encryption 
algorithms 

• bandwidth manager last 

• dump messages in input queue for starters 

• syslog interface 

Sentry messages sent by probe/sentry system 2000 through Pipes 3000 are received 
by gateway system 4000 at the SOC and transformed into gateway messages. Such 
transformation may include reformatting of the data in the sentry messages and/or 
appending of additional data. (TABLES 6 and 8 of Appendix C provide forms which 
might be incorporated into SOCRATES 6000 for storing information regarding formatting 
of messages sent to and from various gateway systems 4000.) The gateway messages are 
then forwarded, via internal network 5000, on to problem and expertise management 
("SOCRATES") system 6000 (hereafter referred to as "SOCRATES 6000"). Gateway 
system 4000, as well as SOCRATES system 6000, can be implemented in software or 
hardware or a combination of software and hardware. 

SOCRATES 6000 manages the problem resolution process, including (i) storing, 
managing and processing various kinds of information useful for problem resolution and 
response; and (ii) generating, from received gateway messages and other information, 
"problem tickets" representing potential security-related happenings on the customer's 
network. The kinds of information managed by SOCRATES 6000, which can be stored in 
various databases 6020, can include security intelhgence, customer information, and 
problem resolution information. TABLE 1 of Appendix C provides a more detailed listing 
of the types of databases which might be employed in an embodiment of SOCRATES 
6000. TABLES 2-1 9 of Appendix A provide possible information which might be 
incorporated into such databases. 

MSM service security analysts receive problem tickets for handling access 
information useful for problem investigation, resolution and response, and otherwise 
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interface with SOCRATES 6000 via security analyst consoles 6010, For security reasons, 
consoles 6010 can be configured so that a given security analyst can have only a limited 
ability to look at data and/or perform tasks (for example, the security analyst might be 
given access to only the keyboard and monitor of each terminal and/or token-based 
authentication might be required for access to systems). In an exemplary embodiment, 
each security analyst at a SOC sits at a console 6010, and each console 6010 has three 
terminals, two secure internal SOC terminals and one secure external terminal. The 
external terminal can provide secure access to the Internet and to the MSM service's 
corporate network. The internal SOC terminals can be connected to seciure, 
fully-redundant computers containing, among other things, SOCRATES 6000, a web 
browser for internal pages, an operations guide, and training materials. Depending on 
requirements, software for consoles 6010 could be written in Java for easy porting to a 
wide variety of hardware or be based on certain preexisting conunercially available 
software (for example, automated call database software). 

The operation of SOCRATES 6000 can be controlled by operating procedures 
6030, which can be tailored to specific customers' needs. Such operating procedures can 
include, for example, specifying which customer contacts should be notified about what 
types of events during which hours of the day and how to respond to certain types of 
attacks. (TABLE 4 of Appendix C suggests a database forin capable of providing such 
information.) Workflow functionality and business rules may also be developed using the 
SOCRATES system. Such rules can be implemented, for example, using a combination of 
active links, macros and filters. (TABLES 20-22 of Appendix C provide examples of 
possible resources that might be implemented on an embodiment of SOCRATES 6000.) 

SOCRATES 6000 can generate a variety of reports for customers or internal use 
through report generation module 6040. For example, a current report may be sent to and 
accessed directly from probe/sentry system 2000. This report can be web-based and can 
include the status of the probe/sentry system, the status of open tickets and detailed log 
information. A weekly report could include incident summaries, open ticket summaries, 
details on critical and suspicious events, and sensor reports, and could be emailed to the 
primary customer contact. The weekly report could also include trend analysis of data 
covering monthly, quarterly and "to-date" data collections and could contain a variety of 
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report sections, including ticket summary (including accumulation of events by type for 
the week, month, quarter, year), critical tickets summary, top ten events (mcluding.weekly, 
indnthly, broken down by event type), known attackers list, top ten targets list, IP watch 
list (including attack occunrences broken down by day and time), probe/sentry statistics, 
and known device list. 

Report formats can include paper, email or web-based delivery in approximately 
real time. For security reasons, in a preferred embodiment, web-based connections for 
deliveiy of reports can be cryptographically protected, and sending and receipt of such 
reports authenticated using digital certificates. 

SOCRATES 6000 can send alerts 6050 to MSM service personnel or customer 
contacts. Such alats can be delivered by a wide variety of means including email, pager, 
telephone and cellular phone depending on a variety of factors, including the customer's 
needs, the configuration of the MSM service for the particular customer and contractual 
tenns in a service level agreement. In a preferred embodiment, SOCRATES 6000 can 
maintain audit logs of all alerts issued, for tracking and other purposes. 

FIG. 2 is a system overview of an exemplary embodiment of a probe/sentry 
system. One or more such systems can be installed at each customer site to monitor the 
customer's network and network components. (A database of all network components 
monitored by such probe/sentry systems may be stored by SOCRATES 6000 in a database 
similar to that suggested in TABLE 7 of Appendix C.) Data collected by sensors 1010, 
1020, 1030 and 1040 (note that four sensors are shown solely by way of example and are 
not meant to limit the scope of the invention) are collated by sensor data collator 2010. 
Once collated, the data is first filtered by negative filtering subsystem 2020, which 
discards uninteresting information, and then by positive filtering subsystem 2030, which 
selects possibly interesting information and forwards it to communications and resource 
coordinator 2060. Data neither discarded by negative filtering subsystem 2020 nor 
selected out as interesting by positive filtering subsystem 2030 form the "residue," which 
is sent to anomaly engine 2050 for further analysis. Anomaly engine 2050 determines 
what residue information may be worthy of additional analysis and sends such information 
to communications and resource coordinator 2060 for forwarding to the SOC. Negative 
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filtering, positive filtering, and residue analysis are examples of data discrimination 
analyses, other types of which are well-known to those skilled in the art. 

Communications and resource coordinator 2060 creates sentry messages out of the 
interesting status data and forwards those messages on to gateway system 4000 via Pipes 
5 3000. In a preferred embodiment, each sentry message has a sentry identification number 
(uniquely identifying the sending sentry) as well as a message identification number 
(identifying the type of problem). (TABLE 6 of Appendix C suggests other information 
that might be included in such a message.) Communications and resource coordinator 
2060 can also manage software updates to probe/sentry system 2000, such as updates to 
10 filtering subsystems 2020 and 2030, sent by the SOC. Communications and resource 
coordinator 2060 can also monitor a "heartbeat" passing between probe/sentry system 
2000 and gateway system 4000. 

Pipes client 301 0 on the probe/sentry end handles sentry messages generated by 
communications and resource coordinator 2060 and sends those messages through Pipes 
15 3000 on to gateway system 4000. Pipes client 3010 also services queues of incoming 
' messages from and outgoing messages to the SOC. 

Customer reporting subsystem 2040 allows a customer to, among other things, 
check the status of problems that are being worked on by security analysts at the SOC. 
The SOC can have the ability to push web pages onto probe/sentry system 2000 at the 
20 customer's site via Pipes 3000. These pages then are directed by communications and 

resource coordinator 2060 to customer reporting subsystem 2040. Preferably, a customer, 
once authenticated, can view such pages using any browser. 

Network response subsystem 2070 can, among other things, process and execute 
requests originating firom the SOC designed to mitigate or terminate various attacks; For 
25 example, network response subsystem 2070 might be requested by the SOC via Pipes 
3000 to not allow a certain IP address to access the customer's network for the next 10 
minutes. Such a "fix" might be sufficient to stop a transient attack, such as someone 
repeatedly trying to log in to the customer's network. 

Execution integrity monitor 2080 (which may have a redundant backup) monitors 
30 the functioning of each of the components of probe/sentry system 2000 and communicates 
with the SOC via Pipes 3000 in the event that it detects any malfunction. 
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FIG. 3 is a system overview of an exemplary embodiment of a gateway system. 
Sentry messages bom probe/sentry system 2000 travel through Pipes 3000, arrive first at 
Pipes server 3020 (which manages queues of messages incoming from and outgoing to 
various probe/sentiy systems) and then are passed to communications and management 
coordinator 4020. Sentry update manager 4010 manages updates, such as software and/or ' 
filter updates, to probe/sentry system 2000. Communications and management coordina- 
tor 4020 converts sentry messages into gateway messages. Analyst problem reporting 
interface 4040 then passes these gateway messages on to SOCRATES 6000 via internal 
network 5000. 

FIG. 4 is a system overview of an exemplary embodiment of a "SOCRATES" 
problem and expertise management system. The SOCRATES system is a consolidated 
system used to manage customers* problems and the supporting data helpful in resolving 
such problems. It provides security analysts at a SOC a single, integrated system with 
which to track information concerning, for example, problems, companies, people, 
contacts, tools, and installed network components and known vulnerabilities. In an 
exemplary embodiment, the SOCRATES system can include the following capabilities: 

• communications with probe/sentry systems; 

• email integration; 

• access and authority management; 

• escalation and notification management; 

• report development; 

• probe/sentry management through gateway systems; 
distributed database; 

• generation of web-based reports; 

• addition of servers (as required); 

• call desk/telephone system integration; 

• paging integration; 

• customer surveys; and 

• service level agreement fimctionality. 

In an exemplary implementation, processing of gateway messages by SOCRATES 
6000 proceeds as follows. Gateway messages arrive at SOCRATES 6000 fiT>m gateway 
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system 4000 via internal network 5000. SOCRATES 6000 first creates fi-om these 
gateway messages "event records," which can be stored in problem/event database 6021 . 
Event records may then be hnked with other event records stored in problem/event 
database 6021 and with information from a variety of databases (including customer 
5 information from client information database 6022 and problem resolution information 
from problem/event resolution database 6023) to form "problem tickets," which are then 
opened and displayed on security analyst consoles 6010 to security analysts for handling. 
(Appendix C provides more detail on information that might be included in the client 
information database 6022 (see TABLES 3, 4, 7, and 9), the problem/event resolution 

10 database 6023 (see TABLES 13, 14, 18, and 19) , and problem tickets (see TABLE 10)). 

Alternatively, event records reflecting a problem already reflected in an existing and open 
problem ticket may simply be linked to such open ticket. Redundancy of the SOCRATES 
system may be achieved by connecting SOCRATES 6000 to SOCRATES Duplicate 8000 
via secure private networic connection 7000. 

15 Problem/event resolution databiase 6023 can include, among other things, a 

database of vulnerabilities. Such a database of vulnerabilities can contain a table or 
"form" having an entry for each known vulnerability. Vulnerability intelligence may be 
developed in-house or acquired fix)m outside sources and maintained within the SOCRA- 
TES system. In the event vulnerability information from more than one outside source is 

20 duplicative or conflicting, the SOCRATES system can maintain a table or "form" for each 
vendor of vulnerability infomiation. For a more detailed description of possible embodi- 
ments, refer to TABLES 1 1 and 1 7 in Appendix C. 

FIG. 5 is a flowchart showing an exemplary implementation of incident handling 
by a security analyst. In step 500, a security analyst is notified by his or her console that a 

25 problem ticket has arrived. In step 505, the security analyst picks up the ticket, and in step 
510, he or she begins to investigate it. If more information is needed from the customer 
(step 515), the analyst can contact the customer to get such information (step 520). (A 
preferred embodiment of the invention may contain forms that provide pertinent infonna- 
tion about the customer and its contactis, as provided by way of example in TABLES 3, 4 

30 and 9 of Appendix C). Otherwise, in step 525, the analyst determines whether he or she 
can handle the ticket or whether the ticket needs to be escalated. If the ticket needs to be 
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escalated (step 530), the ticket can be transferred to another analyst (or security engineer) 
for investigation (step 510). Once an analyst (or security engineer) is capable of handling 
the ticket, he or she determines, in step 535, the symptoms, vulnerabilities and recom- 
mended solutions associated with the ticket. For example, the analyst (or security 
engineer) may use SOCRATES 6000 to match the observed symptoms of the attack to a 
known vutoerability. The analyst (or security engineer) can then search SOCRATES 6000 
and its associated security intelligence and other databases for possible solutions. In step 
540, the analyst (or security engineer) determines an j^propriate response level, and in 
step 545, he or she initiates such a response. 

By knowing the vulnerability, a security analyst should be able to properly respond 
to the customer, at a response level commensurate with the severity level of the incident. 
In a preferred embodiment, responses should be predetermined to the extent possible (for 
example, effective responses to identical incidents in the past can be repeated) in order to 
shorten response time. For security reasons, in a preferred embodiment, all customer 
communications should be initiated from within the SOC. Responses to events of 
differing severity levels might proceed as follows: 

interesting Events: The customer is provided online and/or weekly reports. 
Security-Relevant Events: The security analyst sends an encrypted email alert to 
the customer contact detailing the type of event, ticket number, symptoms, vulnera- 
bility and possible solutions for resolving the incident. The email alert can also 
include a URL to a secure website where the customer (after authentication) can 
access further detailed information. 

Suspicious Events: The security analyst initiates a phone call to the customer 
contact. If the customer contact is not available, the analyst leaves a message and 
proceeds to call the next customer contact. Once a customer contact is on the 
phone with the security analyst, a customer contact authentication process begins. 
If authentication is successful, the security analyst can inform the customer of the 
incident and offer solutions to resolve the problem. An encrypted e-mail message 
can also be sent to the customer informing him of the incident and possible 
solutions. 



wo 01/71499 PCTAJSOl/07629 

17 

Critical Events: The security analyst initiates a phone call to the customer contact. 
If customer contact is not available, the analyst leaves a message and proceeds to 
call the next customer contact. Once a customer contact is on the phone with the 
security analyst, a customer contact authentication process can begin. If authenti- 

5 cation is successful, the security analyst can inform the customer of the incident 

and offer solutions to resolve the problem. After speaking with the primary 
contact, the security analyst can initiate another phone call to the customer man- 
agement contact. The analyst can then inform the customer management contact 
about the incident and relate to whom the analyst previously reported the incident. 

10 An encrypted e-mail message can also be sent to the customer contact and cus- 

tomer management contact informing them of the incident, possible solutions and 
whom the analyst contacted about the incident. 

Once the problem has been deah with and resolved, the analyst, in step 550, enters 
details of the incident, along with the associated symptoms, vulnerabilities and solutions 

15 into SOCRATES 6000 and then closes the ticket (step 555). (TABLES 12, 17, and 5 of 
Appendix C provides more detail on information that might be included regarding 
symptoms, vulnerabilities, and diagnoses, respectively.) 

Following ticket closure (for example, one or two days later), MSM service 
custorher service personnel can send to the customer an incident survey to get the cus- 

20 , ^tomer*s comments regarding how the incident was handled. In addition, a phone call may 
be placed to customers whose tickets were critical in nature to make sure the incident was 
resolved and to get a final ''all clear/' When all issues have been resolved, customer 
service can stamp a complete closure on the ticket. An authenticated customer acknowl- 
edgment can be required before a critical or suspicious ticket is closed. If unresolved 

25 issues are discovered or there are problems that occurred due to the solutions provided by 
the security analyst, customer service can immediately reopen the ticket, route the call to a 
security engineer, and inform the appropriate SOC manager that the ticket needs immedi- 
ate handling. 

FIG. 6 is a diagram illustrating exemplary escalation scenarios for various types of 
30 escalation (incident, customer service and technical support) in an exemplary embodiment 
of the present invention. For problem resolution purposes, an incident may be escalated 
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from security analysts to senior security analysts to security engineers and finally to the 
network intelligence and engineering organizations of the MSM service itself. Where 
customer service issues arise, escalation may proceed from the security analysts to the 
customer service organization of the MSM service to MSM service and customer manage- 
ment. Where technical support issues arise, escalation may proceed from a security 
engineer to the network intelligence and engineering organizations of the MSM service to 
the customer service organization of the MSM service. If necessary, customer service can 
coordinate with MSM service and customer management to arrange for outsourced field 
engineering personnel to provide any necessary technical support, including on-site 
support. 

Escalations are primarily intended to prevent open problems from going unrecog- 
nized. Escalation procedures should therefore be designed to identify those open problems 
that may have been overlooked or that require additional attention. Ideally, the number of 
open problems that satisfy this condition should be relatively low and represent the 
exception rather than the rule. 

Escalations may be of various types, including time-based and event-driven. 
Time-based escalations can be intended to capture problems that have remained in a 
particular state beyond a specified period of time. Event-based escalations can be 
designed to trigger immediately when a predefined condition is met. When escalation 
criteria are met, workflow procedures can be defined to perform one or more actions. 
Examples of such actions include: 

• sending notification of the problem to the appropriate group or individual; 

• reassigning the problem; 

• escalating from first level support to second level support to manager of the day; 

• escalating to upper management; 

• generating a report for the problem; and 

• incrementing or decrementing the priority of the problem. 

In the case of a time-based escalation, guidelines may be established for the 
maximum amount of time that a problem can remain unresolved before specific actions are 
taken. Normally, a solution cannot be guaranteed within a specific time frame but, in a 
preferred embodiment, support personnel can represent that within a certain amount of 
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time, the problem will either be resolved or escalated by bringing additional resources to 
bear. 

Escalation procedures can help ensure that the time frames for problem resolution 
are being met and that no problem remains unresolved. These time frames can be built 
5 into the SOCRATES system with predetermined triggers that automatically escalate an 
incident based on the length of time it goes without valid resolution. For example, 
escalation in the form of notifying the assigned-to group might be required if a problem 
remains in an "open" or "assigned" state for longer than 60 minutes. 

Operating procedures for the MSM service can also include procedures for 

10 handling incoming calls of various types. Possible call types can include incident-related 
calls, customer service related calls, technical support*related calls and sales related calls. 
Incident related calls can include customer callbacks due to an existing problem ticket (for 
example, returning a security analyst's call, calling regarding ticket closure or calling 
requesting more support on an incident) and customer cold calls (for example, reporting an 

15 incident not flagged by the probe/sentry system and sent to the SOC). 

FIG. 7 is a flowchart illustrating an exemplary implementation of a customer call 
handling procedure for a call arising from an existing problem ticket. In step 700, an 
incoming call is screened by a customer service representative or an analyst. In one 
embodiment, incoming calls during business hours could be flrst answered by a customer 

20 service representative, while calls after business hours could be directly routed to security 
analysts at the SOC. In step 70S, the representative or analyst gathers information about 
the customer and the nature of the call. In step 710, the call is transferred to the analyst 
who originally responded to the problem ticket, if he or she is available (step 7 1 5). If not, 
the customer may be given a choice to leave a message for the originating analyst or be 

25 routed to another available security analyst within the same SOC (step 720). If another 

analyst is available at the same SOC (step 725), he or she can process the ticket (step 730). 
Otherwise, the customer can be routed to an analyst at another SOC, who will then process 
the ticket (step 735). After processing is complete, the ticket is closed (step 740). 

FIG. 8 is a flowchart illustrating an exemplary implementation of a customer call 

30 ' handling procedure for a cold call resulting from an event that a customer has found on its 
own network. In step 800, the call is screened by a customer service representative or 
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analyst, who, in step 80S, gathers information about the customer and the nature of the 
call. In a preferred embodiment, the call is then transferred to the customer's home SOC. 
If there is no available security analyst in the customer's home SOC, the call may be 
routed to an available security analyst in another SOC. In step 810, the analyst checks the 
appropriate SOCRATES database to make sure there are no open or closed tickets for the 
incident being reported. If there is an open ticket (step 815), the analyst will proceed to 
process the ticket (step 820). If there are no open or closed tickets pertaining to this 
incident, the analyst will proceed to open a new ticket (step 825). In step 830, the analyst 
gathers information bom and authenticates the customer. In step 835, the analyst gathers 
symptom information. In step 840, the analyst determines whether he or she can handle 
the ticket. If not, the ticket may be escalated to the next level in accordance with FIG. 6, 
for example, to a security engineer (step 845). In step 850, the analyst (or security 
engineer) analyzes the ticket and matches symptoms to vulnerabilities to possible solu- 
tions. In step 855, the analyst (or security engineer) calls the customer to provide possible 
solutions, and, in step 860, places the customer in a "watch state." In step 865, the analyst 
(or security engineer) tries to determine from the information provided by the customer 
why the probe/sentry system on the customer's site failed to capture the event, and, in step 
870, he or she informs the next level escalation of any problem with the functioning of the 
probe/sentry system. In 875, the analyst (or security engineer) determines whether the 
solutions provided have solved the problem and whether the customer is now in an "all 
clear" state. If yes, in step 880, the ticket can be closed. 

Customer service related calls can include customer relationship calls (for example, 
customer complaints, customer comments, and other customer satisfaction related calls), 
change management calls (for example, requests to change contact information, requests to 
change filters, requests to add or remove services, requests or notifications regarding 
movement of equipment and change orders) and information requests (for example, 
questions regarding current services, report requests, services requests and questions 
regarding future services). Customer service related calls may be processed similarly to 
other calls. In an exemplary embodiment, processing of customer service related calls 
could begin with opening a ticket. Customer service personnel would then gather 
information from the customer for authentication and then process the ticket according to 
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the customer's needs. If the call required escalation, customer service could escalate the 
call to the appropriate team or management person best suited to handle the situation. 
Customer service would then follow up with the team or management person until the 
situation was resolved. At this point, the ticket could be closed. 

Technical support related calls can include (i) customers calling the SOC for 
general support of their security devices and (ii) customers calling the SOC due to failures 
in the their networks resulting from solutions provided by the SOC. An exemplary 
response protocol for the first type of call might be as follows: First, the security analyst 
opens a ticket, gathers all customer information required, and notes any questions the 
customer may have. The security analyst then determines if he or she can handle all of the 
customer's inquiries. If not, the ticket is escalated to a security engineer. The security 
analyst or security engineer then will answer all of the customer's questions to the best of 
their ability. If the customer requires in-depth product support of a product not supplied 
by the MSM service, the security analyst or security engineer can advise the customer to 
contact the manufacturer of the product for more detailed technical support. At this point, 
the security analyst or security engineer can proceed to close the ticket. 

An exemplary response protocol for the second type of technical support related 
call might be as follows: Any call from a customer reporting a network failure due to a 
solution provided by the MSM service can immediately be escalated to a security engi- 
neer. The security engineer will help the customer to the best of his or her ability. If the 
security engineer carmot help the customer over the phone and the customer requires an 
on-site visit, the ticket is escalated to customer service. Customer service then determines 
how best to serve the customer. The ticket may require a security engineer to go to the 
customer's site. Altematively, the ticket may be referred to a business partner of the MSM 
service for an on-site visit. When an "all clear" signal is received from the customer, 
customer service will proceed to close the ticket, prior to which all details about the 
incident and responses, including any solutions implemented, should be logged into 
SOCRATES 6000. 

Sales related calls can include calls from potential customers inquiring about the 
MSM service. Such calls may be processed similarly to other calls. In an exemplary 
embodiment, processing of an incoming sales call could start with opening a ticket. The 
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customer service representative or security analyst should gather information from the new 
or potential customer and forward it to sales. The security analyst or customer service 
representative should also log the name of the sales representative and the time and date 
the call was referred to sales. 

FIG. 9 is a flowchart illustrating, in greater detail, an exemplary implementation of 
the problem ticket generation and handling process. In step 900, the probe/sentry sends 
information about noteworthy events on the customer's network, in the form of sentry 
messages, to the gateway system at the SOC. Each sentry message is tagged with a sentry 
identification number ("sentry ID") and a message identification number ("message ID"). 
Message IDs reflect the nature of events happening on the customer's network, such that 
substantially identical events (for example, multiple incorrect logins to the same server) 
will result in identical message IDs. 

In step 902, a gateway message or "event record," still tagged with the same sentry 
ID and message ID, is created by the gateway system at the SOC. In step 904, a decision 
can be made to create a new problem ticket if the severity of the gateway message/event 
record is greater than some threshold (for example, "interesting") and the sentry ID and the 
message ID are different from that of any already opened problem ticket. If the sentry ID 
and message ID are identical to that of an already opened problem ticket, a message will, 
in step 906, be written to an event log and the aggregation count associated with the 
particular problem ticket will be incremented by one. 

In step 910, a problem ticket is created. In a preferred embodiment, the majority of 
problem tickets will be created automatically by SOCRATES 6000 as a result of gateway 
messages spawned by sentry messages sent 6om the probe/sentry system. Problem tickets 
may also be created manually (step 908) by a security analyst or other SOCRATES 
operator using a SOCRATES form. The status of problem ticket may be set to one of a 
number of states. Once created, the status of the problem ticket is set to "open" (step 912) 
and, in step 914, the default assigned-to group is notified. In step 916, if the problem 
ticket cannot be assigned, an escalation notification is generated, in step 91 8, and assign- 
ment is reattempted. Once assigned, the status of the problem ticket is set, in step 920, to 
"assigned." In step 922, if the assigned security analyst (or "operator") is not working on 
the problem, the problem can be escalated, in step 924, until the problem is being worked 



wo 01/71499 PCT/USOl/07629 

23 

on, at which point the status is set, in step 926, to "in progress." In step 928, the security 
analyst checks customer contact infomiation, vulnerability information and previous cases 
involving similar incidents in a search for possible solutions. In step 930, the security 
analyst decides whether communication with a customer contact is necessary. If yes, in 

5 steps 932, 934 and 936, the security analyst tries to reach the customer contact through 
various avenues until he or she is successful or all avenues have been exhausted. If all 
avenues have been exhausted, the ticket status is set, in step 938, to "pending," and the 
security analyst will check such pending tickets periodically (step 940). If the security 
analyst is able to reach the customer contact or commimication with the customer is 

10 unnecessary, problem resolution can continue. The security analyst works on the problem 
until the problem is ready to resolve (step 942). During this time, the status of the problem 
ticket is set by the operator or analyst to "ongoing" (steps 944 and 946). Once the problem 
is ready to resolve, the security analyst changes the status of the problem to "resolved" 
(steps 948 and 950). In step 952, the ticket is closed, either automatically, by escalation 

15 setting the status to "closed" (step 954) or manually, by the security analyst setting the 
status to "closed" (step 956). In step 958, the ticket is closed. 

Modifications, Enhancements and Alternate Embodiments 

The foregoing has described various aspects of an exemplary implementatidn of 
the present invention, directed at monitoring, detecting and responding to computer 

20 network intrusions. Those skilled in the art will realize, however, that the present 

invention is usable generally for (i) monitoring of any system; (ii) filtering the data fi^om 
the monitoring for noteworthy events happening in or affecting any system; (iii) alerting 
human beings to any such noteworthy events; and (iv) providing for a response by human 
beings to any such alert. 

25 As one example, the present method could be applied to providing security 

monitoring, detection and response for a residence or business. For example, such a 
service might monitor alarm or other status data, filter such data for security-related 
events, alert a human being upon such a security-related event, and provide for a human 
response to the alert. 
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Therefore, it is intended that the scope of the invention be limited only by the 
claims appended below. 
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APPENDIX A 

Exemplary Pipes Protocol 

Message Format 

In a preferred embodiment, the Pipes message format should be easy to parse and 
human readable to the extent possible without interfering with parsing. Each header field 
can be separated by spaces. Values can be either printable hex (lower case for letters) or 
alphabetic mnemonics. 

A message can consist of a fixed header followed by a body. An exemplary format 
for the header is as follows: 

HHHH - length (printable hex, 4 characters, range 0..nn) 

SPACE - one character, hex 0x20 

HHHH - revision (printable hex, 4 characters) 

SPACE 

SSSS - sentry number (printable hex, 4 characters) 
SPACE 

HHHH - reference number (printable hex, 4 characters) 
SPACE 

STATUS - status code for each message 
SPACE 

KMAC value (always "X" for now) 
SPACE 

XXXX - opcode (4 printable ASCII characters) 
SPACE 

PAYLOAD - (length) bytes, in printable hex, max 2048 characters less header 
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"OOlf 0000 3333 1111 2222 X ALRT 12345678" 
Notes 

1. All the above fields should have spaces between them. 

2. The first four-digit group is the length of everything after it (LENGTH) (the 
space through the end of "12345678"). 

3. The second four-digit group is the revision field (REVISION). 

4. The third four-digit group is the probe/sentry number, which identifies a 
particular probe/sentry ("3333" in the example). 

5. The fourth four-digit group is the reference number defined by the 
probe/sentry system (REFNUM)(" 1 1 1 1" in the example). 

6. The fifth four-digit group is the status number defined by the probe/sentry 
system (STATUS) ("2222" in the example). 

. The next one-digit field ("X") is the keyed Media Access Control (KM AC) 

value, if present. If not present, the value should be an "X." 

8. The next field is the op code (OPCODE). For filter-related messages, it is 
always "ALRT." 

9. The portion of the message after the space after "ALRT" is con- 
tent-specific. 

Field Descriptions . 

REVISION - a version number, consisting of a major and a minor value. Minor revisions 
should be compatible with previous revisions within the same major number range. 

LENGTH - the length in characters of the message that follows the header. 
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REFNUM - a reference number generated by the initiator of the message exchange. For 
PING and other multi-message exchanges, the REFNUM of the response should match the 
value in the request. 

STATUS - a status code indicating the severity of the message. Messages are sorted in the 
5 hold queue according to priority (status codes numerically larger than n are sent first). 

KMAC value - 'X* or 32 characters representing a 16 byte keyed MD5 hash of the entire 
message, including the header, with the KMAC (Keyed MAC) preset to zero. 

OPCODE - printable value indicating the message operation code (i.e., "ALRT"). 

PAYLOAD - the core content of the message. 

10 Sample Pavload Descriptions 

ALERT 

Opcode "ALRT" 

This message is sent from the probe/sentry to the gateway by the probe/sentry filtering 
subsystem. An ALRT payload contains (after decoding to binary): 
IS 0..1ast - block of probe/sentry alert data 

INITIAL CONTACT 
Opcode "INIT" 

This message is sent from the probe/sentry to the gateway when the probe/sentry first 
connects to the gateway. An INIT payload contains (after decoding to binary): 
20 0..3 - connect type: O000==normal, 0001=must-be-accepted 
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INITIAL CONTACT ACK 
Opcode "INAK" 

This message is sent from the gateway to the probe/sentry in response to an INIT. 

0..3 - response status: O000=ok/accepted, 0001=go away 
Note: a "go away" response should not be acceptable if the probe/sentry used the "must be 
accepted" connect type. 

PING 

Opcode "PING" 

this message is sent from (either end) to determine if the other end is alive. A PING 
payload contains (after decoding to binary): 

0...1ast null terminated text data containing memory used, number of alerts 
sent, etc. 

PING ACK 
Opcode "PACK" 

This message is sent in response to a PING. A PACK payload contains (after decoding to 
binary): 

0..3 - first four bytes of PING message. 

TEST 

Opcode "TEST" 

This message is sent from (either end) to respond to a test message. A TEST payload 
contains (after decoding to binary): 
0..1ast test data 

TEST ACK 
Opcode "TSAK" 

This message is sent from (either end) to respond to a test message. A TSAK payload 
contains (after decoding to binary): 

0..3 first four bytes of the test message 
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UPDATE EXECUTE 
Opcode "UPEX" 

This message is sent from the gateway to the probe/sentry to cause an update to be 
executed. A UPEX payload contains (after decoding to binary): 

0..1ast null terminated ASCII path, from root, of shell script to execute to force 
update 

UPDATE EXECUTE ACK 
Opcode "EXAK" 

This message is sent from the probe/sentry to the gateway to acknowledge a UPEX 
message. An EXAK payload contains (after decoding to binary): 
0..3 network byte order return code from script. 

UPDATE FRAGMENT 
Opcode "UFRG" 

This message is sent from the gateway to the probe/sentry to send an update. An "update" 
is a file that may be stored in a directory such as "/MSM/update/<id>", where "id" is the id 
value from the message. A UFRG payload contains (after decoding to binary): 

0..3 - network byte order offset within update 

4..7- ID of update 

8..last - contents of update fragment 

UPDATE FRAGMENT ACK 

Opcode "UFAK" 

This message is sent from the probe/sentry to the gateway to acknowledge a UFRG 
message. A UFAK payload contains (after decoding to binary): 

0..3 network byte order offset of last byte of update received. 
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The configuration details of one possible production environment for the SOCRATES 
system are as follows: 

AR System Details 

AR System Version: 4.03 

AR Client Version: 4.03 

AR Admin Version: 4.03 



HAV Platform Details 

Hardware: 
Operating System: 
Hard disk space: 

Memory: 

Disk Configuration: 
# CPU's: 



Sun Ultra Enterprise 450 
Solaris 7.0 
256 GB 
1 GB 

RAID 5 or RAID 10 (to be determined) 
2x400mhz 



Database Details 

Vendor: 

Allocated Disk Space: 

Client Details 

Operating System: 
Monitor Resolution: 



Oracle 8.x 

To be determined 

NT 4.0 Workstation 
1024x768 
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The configuration details of one possible development environment for the SOCRATES 
system are listed below: 

AR System Details 

AR System Version: 4.03 

AR Client Version: 4.03 

AR Admin Version: 4.03 



H/W Platform Details 

Hardware: 
Operating System: 
Hard disk space: 
Memory: 

Disk Configuration: 
#CPU's: 

Database Details 
Vendor: 

Allocated Disk Space: 



Sun Ultra 10 Workstation 
Solaris 7.0 
9 GB 
1GB 

To be determined 
1 440mh2 

Oracle 8.x 

To be determined 
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APPENDIX C 

This appendix describes data categories and functionalities that may be employed 
in an exemplary embodiment of the SOCRATES system. Additional data categories are 
possible. Such data elements can be stored in forms, tables or other formats. 

5 The tables provided in this appendix are organized as follows: 

TABLE 1 Sunmiary of data categories 

TABLES 2-1 9 Summary of fields included in each data category described in 
TABLE 1 

TABLES 20-26 Types of active links, filters, macros, notifications, etc. 

10 In TABLES 2-19, the "field type" columns correspond to field types commonly employed 
in programming languages like C, Java, or Fortran. 

TABLE 1. Data Categories 



Data Category (TABLE #) 


Description 


Change Request (2) 


A request to make a change, including suggesting a 
new feature, changing an existing fiinction, report- 
ing a bug, or changing data. 


Company (3) 


Information about a company. 


Contacts (4) 


A matrix of Persons used to decide whom to contact 
and under what circumstances. 


Diagnosis (5) 


The end result of the problem resolution process, for 
example an attack or a normal operating procedure 
that created warnings. 


Gateway Message (6) 


A received Message describing what happened. 


Install (7) 


An installed device monitored by the MSM service. 
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Message (8) 


A type of Message that a gateway may send. 


Person (y; 


Information about a person. 


Problem Ticket (10) 


A consolidation of information regarding a specific 
set of happenings that may indicate an attack, such 
information including gateway messages, company 
mformation and secunty mtelhgence mformation. 


SecurityFocusVulnerability (11) 


Information about system vulnerabilities, which 
may be a combination of custom information and 
information provided by a commercial provider 

cnpri 5IC Qponnf \/17r\r*iic r»/\m 


Symptom (12) 


An in-depth description of a Message. Many differ- 
ciii ivxcobagco may inuicoic uic souic oympiom. 


SymptomToDiagnosis (13) 


Links Symptoms to Diagnoses. 


SymToTechnology (14) 


Links Symptoms to affected Technologies. 


Technology (15) 


An operating system, software product or hardware 
product that may play a role in security. 


TimeZone(16) 


A representation, which may be text, of a particular 
time zone. The representation may be expressed as 

o fiiimnpi' nFVimn*c rpnrpcAntiTicy tVtp HifYIprAtipp fi*Am 

O IIUAiiUwl \Ji, UUUlo 1 vUiCoCllllllg lllw UlllCiCllVW iivill 

GMT. 


Vulnerability (17) 


An exploitable weakness in a Technology. 


VulnerabilityToDiagnosis (18) 


Links Vulnerabilities to Diagnoses. 


VulnToTechnology (19) 


Links Vulnerabilities to affected Technologies. 



TABLE 2. SOC:Change Request 



Name 


Field Type 


Description 


Status 


Radio Button 


Possible states include: New, Assigned, 
Fixed, Rejected, Closed. 
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Request Type 


Radio Button 


Possible states include: Suggestion, 
Change Function, Bug, Required Missing 
Function, Data Request. 


Brief Description 


Char 64 


A brief description of the request. 




Char 155 


ruli name irorn r^ersun recora ui p^don 

who made the request. 


XVCSpOIlol DiCy 

ResponsiblePersonName 


Char 155 


r uli uomc iiuui jrerson recoru ui person 
who should administrate or be resnonsible 
for the request. 


Priority 


Radio Button 


Possible states include: High, Mediiun, 
Low, Implement if Time Allows. 


Memo 


Diary 


A discussion of the problem. 


Attachments 


Attachment 


Attached files relating to the problem 



TABLE 3. SOCiCompanv 



Name 


Field Type 


Description 


CompanylD 


Char 15 


Unique ID for the Company. 


Company Name 


Char 128 


Name of the Company. 


Work Phone 


Char 30 


Telephone number for the front desk. 


Fax 


Char 30 


Main Company fax number. 


WebSite 


Char 255 


Corporate home page. 


Area Code 


Char 10 


Area Code used for geographic location. 


ContactID 


Char 40 


Pointer to the Company Contacts record. 


TimeZone Desc 


Char 255 


Character description of the Time Zone. 


Time Zone 


Real 


Numeric offset from GMT. 


Region 


Char 30 


Company defined region. 


Site 


Char 30 


Company defined site. 


P.O. Box 


Char 10 


Post office box number. 
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Char 10 


Cft-*»fkf niimVif^r 




Char 65 


Street name 


Other Street Info 


Char 65 


Address infbrma^tion other than Street Name and 
Street Number, for example, "100 Plaza East." 


ritv 


Char 65 


Citv 




Char 6S 


r^Aiintrv 




Char 30 


7\t\ nr nfiQtal cnHp 


Mailing Address 


Char 300 


MaiUng address exactly as written on a post enve- 
lope. 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 



TABLE 4. SOCrContacts 



Name 


Field Type 


Description 


Contacts Unique ID 


Char 40 


Unique ID for the Contact 


Descriptionl-10 


Char 60 


Ten descriptions representing 10 different contact 
events. Each contact event can have, for example, 
3 contacts and 3 contact methods. 


Contact 


Drop-Down 
List 


Either or Both. Indicates whether more than one 
contact must be contacted. 


ContactlDAl-BlO 
ContactAl-BlO 


Char 15, 
Char 155 


Full name of the Contact Person. 


MethodAl-BlO 


Drop-Down 
List 


Method of communicating with Contact, including 
Phone, Page and Email. 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 
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TABLES. SOC:Diapiosis 



Name 


Field Type 


Description 


Diagnosis ID 


Char 15 




Type 


Radio Button 


Operational Procedure, Attack, Configuration. 


Name 


Char 60 


Name of particular diagnosis. 


DocumentationStatus 


Drop-Down 
List 


Possible states include: Named, Summarized, 
Described, Reviewed by NI(1), Reviewed by 
Technical Writer, Reviewed NI(2), Approved. 


Summary 


CharO 


A summary description of the diagnosis which 
can used in an initial communication to the 
customer. The description can be somewhat of 
a '^scripted** response the analyst can provide to 
the customer. 


Impact 


Char 500 


A brief description of the impact the diagnosis 
has on the customer. 


Description 


CharO 


A detailed description and discussion of the 
diagnosis. 


Severity 

For Unknown Victim 
rorj\Jiown viciim 
For Mission Critical 
Victim 


Drop-Down 
List 


Possible states include: Critical, Suspicious, 
Relevant, Interesting and Not Defined. Indi- 
cates severity for each category of installed 
device. 


Recommendations 


CharO 


Recommended courses of action. This can be 

uiwr^wii VIUI iillU lliUiv? oU.UvlUIvU UoUl. 


Memo 


Diary 


PertinPTit nntPQ fnr tViiQ rRrrvn^ 


Confirmation 


CharO 


What procedures could be done to confirm this 

is a correct diagnosis. 


CounterEvidence 


CharO 


What procedures could be done to confirm this 
is not the correct diagnosis. 


Attachments 


Attachment 


Pertinent file attachments for this record. 
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TABLE 6. SOCrGatewav Message 



Name 


Field Type 


Description 


GatewayMessagen) 


Char 15 


Unique identifier for this record. 


Company ID 


Char 15 


Pointer into the Company table. 


Company Name 


Char 128 


Name of the Company responsible for the 
probe/sentry that sent the initiating sentry mes- 
sage. 


Attacker IP 


Char 25 


IP address of the device that invoked this attack. 


Vcategory 


Drop Down 


Category of the Victim device. 


Victim IP 


Char 25 


IP address of the Victim device. 


Virtim TD 


Char 45 


Pointer into the Install Table for the Victim de- 
vice. 


Sensor IP 


Char 25 


IP address of the Sensor device that alerted the 
probe/sentry (e.g., firewall, IDS, etc.). 




Char 45 


Pointer into the Install Table for the Sensor 


Qf^ntrv TP 


Char 25 


TP arfHrp^Q of tVif* nrobft/^entrv tbat monitored the 

Sensor. 


Sentry ID 


Char 45 


Pointer into the Install Table for the Sentry 


Problem ID 


Char 15 


Pointer into the Problem Ticket Table for the 
Problem Ticket generated because of this Gate- 
way Message. 


Short Message 


Char 255 


Message text sent by the Sentry. 


Long Message 


CharO 


Message text sent by the Sentry. 


Message ID 


Char 45 


Pointer into the Message Table indicating the 
type of message sent. 


SymptomID 


Char 45 


The Symptom linked to by the Message ID. 


Symptom Name 


Char 128 


The name of the above Symptom. 
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Severity 


Drop-Down 
List 


Possible states include: Cntical, Suspicious, 
Relevant, Interesting and Not Identified. May 
be derived from Symptom and Vcategory. 


Sentry Hardware, 

Product, and Ub 


Char 255 


Information regarding Sentry. Can be taken 

from the Install record pointed to by Sentry ID, 


Sensor Hardware, 
Product, and OS 


Char 255 


Information regarding Sensor. Can be taken 
from the Install record pointed to by Sensor ID. 


Victim Hardware, 
Product, and OS 


Char 255 


Information regarding Victim. Can be taken 
from the Install record pointed to by Victim ID. 


Descl, Valuel, 
Desc2, Value2, 
Liesc^, value:) 


Char 64, 
Char 255 


Genenc parameters sent by the probe/sentry. 


AnacK iinie 


Liaie/ 1 ime 


1 imesiamp ox wnen me anacK occurreo. 


Attack uTime 


Decimal 


Unix representation of the above time. 


Sensor Time 


Date/Time 


Timestamp of when the sensor reported the at- 
tack. 


Sensor uTime 


Decimal 


Unix representation of the above time. 


Gateway Time 


Date/Time 


Timestamp of when the gateway reported the 
attack. 


Sensor uTime 


Decimal 


Unix representation of the above time. 


Grouped Messages 


Radio But- 
ton 


Yes or No. Indicates if this Message is one of a 
group of several messages of the same type. 


Group Count Start, 
Group Count uTime 


Date/Time, 
Decimal 


When the probe/sentry started counting the mes- 
sages in this group. ' 


Group Count Dura- 
tion 


Decimal 


How long (in, for example, milliseconds) the 
probe/sentry counted the messages in this group. 


Message Count 


Integer 


How many messages the probe/sentry counted in 
this group. 
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Name 


Field Type 


Description 




Company ID 


Char 15 


Pointer into the Company Table indicating the 
company that is being monitored. 




Company Name 


Char 128 


Name of the Company. 


5 


Tag Number 


Char 45 


Unique identifier for particular device. 




HardwarelD, 
HardwareName 


Char 15, 
Char 255 


Pointer into Technology table representing the 
Hardware for this device. 




ProductlD, 

IT rOQUv ITN dmc 


Char 15, 
Char 255 


Pointer into Technology table representing the 

Prn^liict fnr tViiQ Hevicft 


10 


OSID, OSName 


Char 15, 
Char 255 


Pointo: into Technology table representing the 
Operating System for this device. 




Status 


Drop-Down 
List 


Possible states include: Ordered, Received, Be- 
mg ASsemoieQ, uepioyea, m KCpair, uown. 
End of Life, Transferred, Delete, In Inventory, 

On T Tian T^iquo^jpH 




^upponcu 


T^aHio T^iittnn 


Ye55 or No Indicate*; whether the MSM service 
supports this device. For probe/sentries this 
normally can be Yes; for Installs that point to 
probe/sentries this normally can be No. 




Sentry 


Radio Button 


Yes or No. Indicates wheth^ or not this Install 
is a probe/sentry. 




Device IP 


Char 25 


The IP address of this device. 


15 


Sentry ID 


Char 45 


The Tag Number of the probe/sentry that this 
Device points to. May be left blank if this In- 
stall is a probe/sentry. 




Machine Name 


Char 64 


Name of the particular device. 




Machine Category 


Drop-Down 
List 


Category of device, including Unknown, 
Known, and Mission Critical. 
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Contact ID, Contact 
Name 


Char 15, 
Char 40 


Pointer into the SOCiContacts table for the con- 
tact matrix. 


5 


Received Date, Re- 
turned Date, Avail- 
able Date, Installed 
Date 


Date/Time 


A series of dates that can record the life of the 
Install. 




CPU Serial Number, 
Monitor Serial Nxmi- 
ber 


Char 64 


Vendor identifying numbers. 


10 


Accessories 


Char 128 


A descnption of penpherals mstalled. 




Installer 


Char 155 


The full name of the person that installed this 
device. 




Owner 


Char 155 


The full name of the person that owns this de- 
vice. 




Department, Floor, 
Room, Cage 


Char 65 


Identifying the location of the Installed device. 


15 


Use Company Loca- 
tion 


Radio Button 


Yes or No. Indicates whether or not to use the 
company location information stored in the 
Company record. 




TimeZone Desc 


Char 255 


Character Descnption oi the 1 ime Zone. 




Time Zone 


Real 


Numeric onset irom UM 1 . 




Region 


Cnar 30 


Company defined region. 


20 


Site 


Lnar iU 


Company defined site. 




P.O. Box 


Cnar lU 


Post office box number. 




Street Number 


Char 10 


Street nimiber. 




Street Name 


Char 65 


Street name. 




Other Street Info 


Char 65 


Address information other than Street Name and 
Number (e.g., 100 Plaza East). 


25 


City 


Char 65 


City. 
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Country 


Char 65 


Country. 


Zip Code 


Char 30 


Zip or postal code. 


Mailing Address 


Char 300 


The mailing address exactly as written on a post 
envelope. 


Router Address, 
Subnet Mask, 
Ethernet Address, 
NATIP, SSH Port, 
rUDllC Jvey, ol^o 
Pa^QwnrH Root 

Password, Other 
Password 


Char 


Specific information about this Install. 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 



TABLES. SOC:Message 



Name 


Field Type 


Description 


Message ID 


Char 45 


Sentry group defined identifier for a message. 


Symptom ID 


Char 45 


Pointer to the Symptom table. 


Name . 


Char 255 


Name of the message. 


Service 


Char 30 


Service to which this message pertains. 


Type 


Drop-Down 


Type of message, including Drop, Forensic, Report, 




List 


Alert. 


Description 


Char 255 


Description of message. 


Pattem(s) 


CharO 


The actual filter pattem(s). Each filter pattern can be 






separated by a new line. 


Memo 


Diary 


Pertinent notes for this record. 
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Name 


Field Type 


Description 


PersonID 


Char 15 


Unique identifier for this person. 


CompanylD 


Char 15 


Pointer into the Company table. 


Company Name 


Char 128 


Name of the above Company. 


Last Name 


Char 65 


Last name. 


First Name 


Char 65 


First name. 


MI 


Char 5 


Middle initial. 


Full Name 


Char 155 


The full name of this person in a particular 
format (e.g., first name first). 


PouTtesv Title 


Drop-Down 


Possible states include: Mr., Ms., Mrs., Miss. 




List 


or Dr. 


Title 


Char 50 


The person's job title (e.g., on the person's 
business card). 


Level 


DnHin T^iittnn 


Prt^^iWe Qtnfp^ inrliiHp' OfFirpr VP F)irector 

Manager, Supervisor, Technician, Other. 


Works in Support 


Radio Button 


Yes, No. 


Wnrlr Phone Work 


Char 30 


Phone numbers that could be used to contact 


Phone2, Fax, Fax2, 




this person. 


Mobile Phone, Home 






Phone 






Email 


Char 255 


Email address of this person. 


CCiEmail 


Char 255 


Email address(es) of those to CC when 
emailing this person. 


Area Code 


Char 10 


Geographically identifies where this person is 
located. 
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Jragcr i^nonc, x^agcr 
Email, Pager Pin, 
Paper Provider 


Char 


imager iniormauun. 


lyCpOi llllwliy X^iV/VJlj 

Room 


Char 6S 


lAK/allUii %Jl. U115 pwloVil* 


Use ComDanv Loca- 
tion 


Radio Button 


Yes or No. Indicates whether or not to use 
the location stored in the Company record. 


TimeZone Desc 


Char 255 


Character description of the Time Zone. 


Time Zone 


Real 


Numeric offset from GMT. 


Region 


Char 30 


Company defined region. 


Site 


Char 30 


Company defined site. 


P O Box 


Char 10 


Post office box number. 


Street Number 


Char 10 


Street number. 


Street Name 

%J U X ^ ***** V 


Char 65 


Street name. 


Other Street Info 


Char 65 


Address information other than Street Name 
and Number (e.g., 100 Plaza East). 


Pitv 


Char 65 


City. 




Char 65 


Country 


Zin Code 


Char 30 


Zip or postal code. 


Mailing Address 


Char 300 


Mailing address exactly as written on a post 
envelope. 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 



TABLE 10. SOC:Problem Ticket 



Name 


Field Type 


Description 


Problem ID 


Char 15 


Unique identifier for this record. 
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Status 


Drop-Down 
List 


Possible states include* Onen Assiened In 
Progress, Pending, Ongoing, Resolved, Con- 
soHdated, Closed. 


CompanylD 


Char 15 


Pointer into the Company table. 


Company Name 


Char 128 


Name of the above Company. 


Priority 


Char 2 


An identifier indicating what to work on 
iirsi. 


Pending Reason 


Drop-Down 

T ict 


Possible states: Waiting for Customer Call- 
oacK, rroDiem is i5emg Moniiorea, v^oiieci- 
ing Report Data, Reoccuring Normal Func- 
tion. 


Source 


Drop-Down 
List 


Possible values: Gateway, Operator, Cus- 
tomer. 


Caller, Caller Name 


Charts, 
Char 155 


Full Name of the person who called. A re- 
cord should 2i1<io he madR in Person 


Assigned Onerator 
AssignedOperatorName 


Char 15, 
Char 155 


Full name of the analvst assi^ed to this 
problem. 


Sentrv ID 


Char 45 


Pointer to the Install record for the 
probe/sentry that reported this problem. 


Sentrv TP 


Char 25 


TP addre^*; of the above nrohe/^ientrv 


Linked Oatewav Mes- 
sages 


Table 


A table of all Gatewav Messages linked to 
this problem. 


1st Svmntom ID 


Char 45 


Pointer into the Svmotom table to the most 
relevant Symptom. 


1st Symptom Name 


Char 65 


Name of the above Symptom 


Diagnoses with the above 

symptom 


Table 


A table of all Diagnoses that are linked to 1st 

Symptom ID. 


Diagnosis ID 


Char 15 


Pointer into the Diagnosis table to proposed 
Diagnosis. 
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Diagnosis Name 


Char 60 


Name of the above Diagnosis. 


nosis 


Table 


A table of all svmntoms linked to the Diae- 
nosis ID. 


/^iiowiw X 111I& 


Date/Time 


Times tamo of when the attack occurred 


Sensor Time 


Date/Time 


Timestamp of when the sensor reported the 

attack 


Gateway Time 


Date/Time 


Timestamp of when the gateway reported the 

flttark 


Create Time 


Date/Time 


Timestamp of when the problem ticket was 
created 


Resolved Time 


UBiCf I ime 


i imestamp oi wnen ine pro Diem iicKei was 

resolved 


Sentry Delta, Gateway 
Delta, Create Delta, Re- 
solved Delta 


Integer 


The nimiber of seconds between two consec- 
utive timestamps. Useful to identify lags in 
the process. 


Department, Floor, 
Room, Cage, Region, 
Site, Street Number, 
street Name, Utner street 
Info Citv State. Coun- 

IIUU, v^lijr, v^v**** 

try. Zip Code, Hardware, 
Product, OS 


Char 


Can be copied from the probe/sentry record. 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 



TABLE 11. SOCrSecuritvFocusVulnerabilitv 



Name 


Field Type 


Description 


Name 


Char 255 


Name of the Vulnerability. 



wo 01/71499 



46 



PCT/USOl/07629 



LinksToVulnerability 


Char 40 


Pointer into the Vulnerability table. 


LinksToVulnName 


Char 255 


Name of the above Vulnerability. 


Bugtraq id 


Char 255 


SecurityFocus.com defined unique identifier 
for this Vulnerability. 


Object, Class, eve, 
published, updated, 
remote, local, Vulner- 
able, Not Vulneraoie, 
v^reaiL, i>>iscussion, 
Exploit, Reference, 
Solution 


Char 


SecurityFocus.com defined information fields 
as described in http://www.securityfocus. 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 


TABLE 12. SOCiSvmDtom 


Name 


Field Type 


Description 


SymptomID 


Char 45 


Unique identifier for this record. 


Name 


Char 128 


Name of this Symptom. 


Severity 

For Unknown Victim 
For Known Victim 
For Mission Critical 
Victim 


Drop-Down 
List 


Possible values: Critical, Suspicious, Relevant, 
Interesting and Not Defined. Indicates severity 
for each category of installed device. 


Description 


Char 255 


A lengfiiy description of this Symptom 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 
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TABLE 13, SOC:SvmDtomToDiagnosis 



Name 


Field Type 


Description 


ID 


Char 15 


Unique identifier for the record. 


Symptom ID 


Char 40 


Pointer to the Symptom record. 


Symptom Name 


Char 255 


Name of the Symptom. 


Diagnosis ID 


Char 15 


Pointer to the Diagnosis record. 


Diagnosis Name 


Char 255 


Name of the Diagnosis. 


Closeness 


Drop-Down 
List 


Possible values: Definitely Not Connected, 
Might Be Connected, Likely Connected, Con- 
nected, Definitely Connected. 



TABLE 14. SOCrSvmToTechnology 



10 


Name 


Field Type 


Description 




Symptom ID, Symp- 
tom Name 


Char 40, 

Char 255 


Pointer to the Symptom record. 




Technology ID Tech- 
nology Name 


Char 15, 
Char 255 


The name of the Technology to which this 
Symptom is linked. 


15 


Relationship 


Drop-Down 
List 


Possible values: Confirmed Unrelated, "Low" 
Relationship, "Medium" Relationship, "High" 
Relationship, Confirmed Relationship. 



TABLE IS. SQCiTechnoloev 



Name 


Field Type 


Description 


Technology ID 


Char 15 


Unique identifier for this record. 


Category 1 


Char 126 


Indicates most general level of categorization 
(e.g., hardware or software). 
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Thar 196 


firewall, etc.). 


Category 3 


Char 126 


Vendor and product (e.g., Microsoft Windows 
NT). 


Category 4 


Char 126 


Version number (e.g., 4.0). 


Category 5 


Pilar 1 "J/I 


OCTYlCc paCK ^Cg., oF^/. 


Name 


Char 255 


Can be a concatenation of Categories 3, 4, and 
5. 


VendorlD, 
VendorName 


Char 15, 
Char 128 


Pointer to Company table indicating the ven- 
dor of this Technology. 


Product Number, De- 
scnpiion, ouppiier 
Name, Manufacturer 
Name 


Char 


Recent information regarding how this Tech- 

ilUlVl^jr Weld |JUlWiladCU< 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 



TABLE 16. SOCrTimeZone 



Name 


Field Type 


Description 


Name 


Char 60 


Text description of the time zone. 


Value 


Real 


Hours difference from GMT. 



TABLE 17. SOC:Vulnerabilitv 



Name 


Field Type 


Description 


Vulnerability ID 


Char 40 


Unique identifier for this Vulnerability. 


Name 


Char 80 


Full name of the Vulnerability. 


Summary 


CharO 


Summary description of the Vulnerability. 
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Description 


CharO 


Detailed technical description of the Vulnera- 
bility. 


AfifectedTechnologies 


CharO 


A hstmg of affected Technologies and con- 
figurations. This data can be additionally 
structured. 


Memo 


Diary 


Pertinent notes for this record. 


Attachments 


Attachment 


Pertinent file attachments for this record. 



5 TABLE 18. SQC:VulnerabilitvToDiagnosis 



Name 


Field Type 


Description 


ID 


Char 15 


Unique identifier for the record. 


Vulnerability ID 


Char 40 


Pointer to the Vulnerability record. 


Vulnerability Name 


Char 255 


Name of the Vulnerability. 


Diagnosis ID 


Char 15 


Pointer to the Diagnosis record. 


Diagnosis Name 


Char 255 


Name of the Diagnosis. 



TABLE 19. SOCrVulnToTechnology 



Name 


Field Type 


Description 


Vulnerability ID, 
Vulnerability Name 


Char 30, 
Char 255 


Pointer to the Vulnerability record. 


Technology ID, 
Technology Name 


Char 15, 
Char 255 


Pointer to the Technology record. 


Relationship 


Drop-Down 
List 


Possible values: Confimied Unrelated, "Low" 
Relationship, "Medium" Relationship, "High" 
Relationship, Confirmed Relationship. 
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TABLE 20. Active Links 



Name 


Description 


SOC'CIPersonNameAl - 
CIPersonNameBlO 


Retrieves a nerson's name based on ID 


SOC:CIPushAl-CIPushB10 


Displays a highlighted contact's personal informa- 
tion at the bottom of the SOCiContacts form. 


iSUL:CUContacis 


Runs the SOC;FindContacts macro when the Con- 
tacts button is pushed on the SOC:Company form. 


oUU .cuv^oniaCisiNaine 


xveineves a coniaci s name oascQ on lu. 


SOC:COGenerateMailingAddress 


Concatenates Address, City, State, Country and 
Zip information into the Mailing Address field 
wnen me vjeneraie jvLaiiing /\uaress ouuon is 
nushed on the SOC'Comoanv form 


^OP-PnTimeZone 


Looks un a TimeZone value when a TimeZone 
name is selected.on the SOC:Company form. 


SOCiCTDisplayPersonRecord 


Runs the SOCrFindPerson macro when the GoTo 
the Full Person Record button is pushed on the 
SOCrContacts form. 


SOC : CRResponsiblePersonName 


Retrieves the person's name based on ID. 


SOCrCRUpdateFrom 


Retrieves the person's name based on ID. 


SOCrDTDisplayPersonRecord 


Runs the Display Person Record macro. 


SOCiINCompanylD 


Looks up the CompanylD when a Company Name 
is selected on the SOC:Install form. 


SOC:INContacts 


Runs the SOC:FindContacts macro when the Con- 
tacts button is pushed on the SOC:Install form. 


SOC:INContactsName 


Retrieves the contact's name based on ID. 
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SOC :INCopyCompany Location 


Copies Company information into the SOCiInstall 
form when the Copy Company Info button is 
pushed. 


SOC iINGenerateMailingAddress 


Concatenates Address, City, State, Country and 
Zip information into the Mailing Address field 
when the Generate Mailing Address button is 
pushed on the SOCiInstall form. 


O f^^^ ~ TTl TT T J— — ■ II ■■ 1 1^ T 11 ■mi ll 

SOC : INHardwareName, 

SOC:INOSName, 

SOCrlNProductName 


Ketneves the Install s name based on ID. 


SOC:INTimeZone 


Looks up a TimeZone value when a TimeZone 
name is seiecxeu on me oc/\^.insiaii lorm. 


o v./L' .iiN u scL'Oinpcuiyj-rUCduoii 


v./nanges iicius irom rcoo oniy lo rcaa wiiic ^dnu 
vice versa) when the Use Company Location radio 
button is selected on the SOC'Install form 


SOC :IP AssignedEngineerPerson 


Retrieves the person's name based on ED. 


SOC:IPCallerPersonName 


Retrieves the person's name based on ID. 


SOC:PECompanyID 


Looks up the CompanylD when a Company Name 
is selected on the SOC:Person form. 


SOC:PECopyCompanyLocation 


Copies Company information into the 
SOC:Person form when the Copy Company Info 
Dunon is pusnea. 


SOC:PEGenerateFullName 


Concatenates First Name, Middle Initial and Last 
Name into the Full Name field when the Generate 
Full Name button is pushed on the SOCiPerson 
form. 


SOC:PEGenerateMaiiingAddress 


Concatenates Address, City, State, Country and 
Zip information into the Mailing Address field 
with the Generate Mailing Address button is 
pushed on the SOC:Problem Ticket form. 
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SOCrPETimeZone 


» Looks up a TiraeZone value when a TimeZone 
name is selected on the SOCiPerscn form. 


SOCrPRAssignedOperatorPerson 


Retrieves the person's name based on ID. 


SOCrPRCallerPersonName 


Retrieves the nerson'^ nAme hsc^ on TD 


SOC:PRCreateDelta 


Calculates Create Delta when Create Time 
changes on the SOCiProblem Ticket form. 


o • Jr ivwicaici^eiuiz 


^aicuiaies ureaie jLieita wnen oateway lime 
changes on the SOC:Problem Ticket form. 


O \J\^ . F Jt>J-/lagIlU51oiN amc 


i^ooKs up me jjiagnosis lu wnen a L/iagnosis 
Name is selected on the SOCiProblem Ticket 
form. 




tlvA O A T #%Aa4'«^^«« 4!a1^A li%«V H«% OaM 

oeis me oenuy LrOcauon neicis oy looiong up oen- 

try ID on Install. 


SOC:PRFillSentryInfolO 


Runs the clearflag macro so that the user is not 
prompxea lo save oaia wnen me user uuiiauy dis- 
plays data. 


SOC:PRFindCompany 


Rims the SOC:FindCompany macro when the 
\^ompany Dunon is pusnea on me oUCrrooiem 
Ticket form. 


SOC:PRFindContacts 


Runs the SOC:FindContacts macro when the Con- 
lacis Duiion IS pusnea on uic o^i^.i^roDiem i iCKei 
form. 




ivuns mc Ovyv^.rinuiiisiaji macro wnen mc ocniry 
button is pushed on the SOCiProblem Ticket 
form. 


SOCiPRGatewayDelta 


Calculates Gateway Delta when Sensor Time 
changes on the SOC:Problem Ticket form. 


S0C:PRGatewayDelta2 


Calculates Gateway Delta when the Gateway 

Time changes on the SOC:Problem Ticket fomi. 
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SOC:PKResolvedDelta 


Calculates Resolved Delta when Create Time 
changes on the SOC:Problem Ticket form. 




SOC:PRResolvedDelta2 


Calculates Resolved Delta when Resolved Time 
changes on the SOCrProblem Ticket form. 




SOCrPRSensorDelta 


Calculates Sensor Delta when Sensor Time 
changes on the SOC:Problem Ticket form. 




SOC:PRSensorDelta2 


Calculates Sensor Delta when Sensor Time 
changes on the SOC:ProbIem Ticket form. 


5 


SOC:PRSymptomName 


Looks up the Symptom ID when the Symptom 
Name is selected from a menu. 




SOC:SDDiagnosisName 


Looks up the Diagnosis ID when the Diagnosis 
Name is selected from a menu. 




SOC:SDSymptomName 


Looks up the Symptom ID when the Symptom 
Name is selected from a menu. 




SOC:SFVulnName 


Looks up the VulnID when the Vulnerability 
Name is selected from a menu. 




SOC:STSymptomName 


Looks up the Symptom ID when the Symptom 
Name is selected from a menu. 


10 


SOC:STTechnologyName 


Retrieves the Technology's name based on ID. 




SOCrTOGenerateTooINameFrom 


Concatenates Categories 3, 4, and 5 into the Tech- 




Cat 


nology Name field in the SOC:Technology form. 




SOC:TORtnOnCatl 


Creates the Category 2 menu based on the result 
of the Category 1 menu. 




SOC:TORtnOnCat2 


Creates the Category 3 menu based on the result 
of the Category 2 menu. 


15 


SOC:TORtnOnCat3 


Creates the Category 4 menu based on the resuh 
of the Category 3 menu. 




SOC:TORtnOnCat4 


Creates the Category 5 menu based on the result 
of the Category 4 menu. 
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S OP • VnDi aenosi sName 


Name is selected from a menu. 


SOP ■ VDVulnerabilitvName 


T .onlcQ im tVip \/iilnTTl wIipti tVip ViilripriiHilitv 

Name is selected from a menu. 


SOC:VTTechnologName 


Retrieves the technology's name based on ID. 


o/^^.^ ymx 7__i ^ T 

SOC:VTVuliiName 


Looks up the VulnID when the Vubierabihty 
Name is selected from a menu. 


SOC:VUFindSecurityFocusVuln 


Runs the FindSecurityFocusVulnerabilty macro 
when the Info from SecurityFocus button is 
pushed. 


TABLE 21. Filters 


Name 


Description 


SOC:GMSubmitEventlO-50 


A series of filters that extracts information for a 
SOC:GatewayMessage record and creates a new 
SOC:Problem Ticket. 


SOC:PRAuditLog 


Provides a record of all field values each time a 
SOC:Problem Ticket is modified. 


SOC:PRFillLastMemo 


Fills in a character field with the last typed in 
memo from the memo field in SOCrProblcm 
Ticket. 


SOC:PRSetSentryEventProbletnID 


Sets the ProblemID field in 
SOCiGatewayMessage whenever a 
GatewayMessage creates a n^ Problem ID. 
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TABLE 22. Macros 



Name 


Description 


SOr 'FindContacts 


Inline ji <iftnrrVi nn ROf^*r^nntartc finr nil pntriM 

matching an input ContactlD. 


SOC "FindPerson 


Inline a cftflTpK rtf QOr^*T^p»rcATi frtr all #*ntrii*c iTmtr*li- 

ing an input PersonlD. 


rlf*flrfla<y 


f^lpflrc tVi^ i^ViflTiQp "flaQ fnr tViP Piirrpnt form 

V^l^CUd lllv VilCUlgC llOA '^^1 lllC L«Ulldll iUlllli 


SOC:FindCorapany 


Runs a search on SOC:Company for all entries 
matching an input CompanylD. 


SOCrFindlnstall 


Runs a search on SOC:Install for all entries match- 
ing an input Tag Number. 


FindSecurityFocusVulnerabilty 


Runs a search on SOC:SecurityFocus Vulnerability 
for all entries matching an input bugtraqid. 



TABLE 23. Menus 



Name 


Description 


SOCrCategoryl 


A list of categories describing this level of a specific Tech- 
nology. 


SOC:Category2 


A list of categories describing this level of a specific Tech- 
nology. 


SOC:Categoiy3 


A list of categories describing this level of a specific Tech- 
nology. 


SOC:Category4 


A list of categories describing this level of a specific Tech- 
nology. 


SOC:Category5 


A list of categories describing this level of a specific Tech- 
nology. 
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SOC:Company 


A list of Companies that return a Company Name when 
sei^cieo. 




/\ iisi ui L^onipanies inai renim a L^ompany uj wnen seieciea. 




/\ iisi oi U'Oniacis. 


dUC :i^agnosis 


A. iisi 01 jjiagnoses. 


SOCrHardware 


A list of Technologies that have Category l="Hardware." 


SOC:Message 


A list of Messages. 


SOCrOperatingSystem 


A list of Technologies that have Category 1= Operating 
oystem. 


SOC:Person 


Alist of Persons. 


SOC:Problem 


A list of Problem Tickets. 


SOCrProduct 


A list of Technologies that are do not have 

L-aiegoryi— riaraware or category i — ^jperating oysiem. 


oUi^'ocnsor . 


/Y 11 SI oi ail insiaiis inai are noi oenines. 


SUCibentry 


A list 01 all installs tnat are oentnes. 


bUC : bymptoms 


A iisi 01 ail oympioms. 


bUC: 1 imeZone 


A list of all TimeZones. 


SOCiTool 


A list of all Technologies. 


SOCiVulnerabilities 


A list of all Vulnerabilities. 



TABLE 24. Notifications 



Notify Individual/Group 


Reason 


Assigned to Group 


Problem submitted. 


Assigned to Group 


Problem reassigned. 


Assigned to Group 


Escalation conditions. 
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SOC:VendorXVulnerability 



SOC:VendorYVulnerability 



Vulnerability information from an outside vendor may be received in a variety of 
fomats. An exemplary format is the following three column text table. 



Name 


Field Type 


Description 


ID 


Char 30 


Unique identifier for this vulnerability 


Local 


Radio Button 


The vulnerability is exploitable locally on the sys- 
tem or device. 


Description 


CharO 


A detailed description of the vulnerability. 


Published 


Date/Time 


The date the vulnerability was made public. 


Other fields ... 







A vendor of vulnerability information can be required to specify fields. When 
specifying fields, the vendor should send the name of the field, a brief description of the 
field and the data type of the field. Some exemplary datatype rules are as follows: 

• Always specify a length for a character field. Char 0 specifies a field that is 
0-64MB of data in length. Use lengths that have a reasonable maximum size (e.g., 
less than 512 characters). 

• Fields with a range of values should have those values listed under the type, for 
example (True, False), (Yes, No) and (Unlikely, Likely, Definite). 

• Date/Time format is preferred for date and time values. If data cannot be sent in 
Date/Time format, then it can be sent as a character field. 

In a preferred embodiment, each vendor of vulnerability information should send 
information in a format that can be imported into a SOCRATES database. One possible 
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format is comma-separated values ("CSV") form. A SOCRATES form can be created and 
a CSV file with the header information can be sent to the vendor. The vendor can then 
email back a CSV file with the vubierability data. This data should be made to adhere to 
certain rules, such as the following: 

• The vendor must create a unique identifier for each row of data. 

On any given set of data, a row of data should be sent only once (no duplicate data 
in a CSV file). 

• To change the data for a vulnerability, send an entire row of data for that imique 
identifier in a download file. 

• The vendor may send the entire set of data in each CSV file or send only changes 
and updates. The decision may be left to the vendor. 

• DateTime is sent in the standard "Month Day, Year" format, for example: 

"October 01, 1988" 



TABLE 26. Naming Conventions 



15 



20 



25 



The SOCRATES system can employ naming conventions and standards to 
facilitate consistent workflow, easy to follow applications, and migration to new versions. 
For example, all SOCRATES forms and menus can be prefixed vnth the characters "SOC" 
followed by a fiill worded description. In addition, all active links and filters can be 
prefixed with the characters "SOC" followed by an abbreviation for the attached form 
followed by a Ml worded description. Exemplary abbreviations for each form can be as 
follows: 



Data Category 


Abbreviation 


SOC:Change Request 


CR 


SOC:Company 


CO 


SOC:Gontacts 


CI 


SOC:Diagnosis 


DI 


SOC:Gateway Message 


GM 


SOC:Install 


IN 
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SOC '.Message 


ME 


SOC:Person 


PE 


SOCiProblem Ticket 


PR 


SOC:SecurityFocusVulnerability 


SF 


SOC* S vmotom 


SY 


SOr* • vmntomToDiaenosi s 


SD 


SOP • S vmToTechnoloev 


ST 


SOC'Technoloev 


TO 


SOC:TimeZone 


TZ 


SOC:Vulnerability 


VU 


SOC:VulnerabilityToDiagnosis 


VD 


SOCiVulnToTechnolpgy 


VT 
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CLAIMS 

What is claimed is: 

1 . A method of operating a probe as part of a security monitoring system for a 
computer network, comprising: 

a) collecting status data from at least one monitored component of said 
network; 

b) identifying potentially security-related events pertainmg to said network by 
analyzing said status data; 

c) transmitting information about said identified events to an analyst associ- 
ated with said security monitoring system; 

d) receiving feedback at the probe based on empirically-derived information 
reflecting operation of said security monitoring system in a manner custom- 
ized to said network; and 

e) dynamically modifying an analysis capability of said probe during opera- 
tion thereof based on said received feedback in a manner customized to said 
network. 

2. The method of claim 1, wherein said identifying step includes performing a 
multi-stage analysis of said status data. ' 

3. The method of claim 2, wherein said multi-stage analysis includes performing a 
discrimination analysis on said status data. 

4. The method of claim 3, wherein the discrimination analysis includes positive 
filtering. 

5. The method of claim 3, wherein the discrimination analysis includes negative 
filtering. 
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6. The method of claim 3, wherein the discrimination analysis includes filtering 
followed by an analysis of post-filtering residue. 

7. The method of claim 2, wherein said multi-stage analysis includes analysis at the 
probe and analysis at a secure operations center configured to receive data from 
said probe. 

8. The method of claim 1 , wherein said identifying step includes aggregating and 
synthesizing said status data at the probe. 

9. The method of claim 8, wherein said identifying stq> includes cross-correlating 
data across said monitored components. 

10. The method of claim 8, wherein said identifying step includes analyzing the 
frequency of occurrence of said events. 

1 1 . The method of claim 1 , further comprismg after said step (c), performing fiirther 
computer-based analysis at a secure operations center configured to receive data 
fix>m said probe. 

12. The method of claini 11, wherein said computer-based analysis includes aggregat- 
ing, synthesi2dng, and presenting alerts on an ensemble basis. 

13. The method of claim 11, wherein said identifying step includes cross-correlating 
data across said monitored components. 

14. The method of claim 11, wherein said identifying step includes analyzing the 
frequency of occuirence of said events. 

15. The method of claim 1 1, wherein said computer-based analysis includes 
cross-probe correlation. 
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16. The method of claim 1 , further comprising instantaneously self-tuning said probe 
based on previously collected status data: 

17. The method of claim 1, wherein said dynamic modifying step includes consider- 
ation of non-real-time information from ongoing security research efforts. 

18. The method of claim 1, wherein said receiving feedback step occurs in substan- 
tially real time. 

19. A computer-readable medium whose contents cause a computer system to operate 
a probe as part of a security monitoring system for a computer network, by per- 
forming the steps of: 

. a) collecting status data from at least one monitored component of said 
network; 

b) identifying potentially security-related events pertaining to said network by 
analyzing said status data; 

c) transmitting information about said identified events to an analyst associ- 
ated with said security monitoring system; 

d) receiving feedback at the probe based on empirically-derived information 
reflecting op^ation of said security monitoring system in a manner custom- 
ized to said network; and 

e) dynamically modifying an analysis ci^)ability of said probe diuing opera- 
tion thereof based on said received feedback in a manner customized to said 
network. 

20. The computer-readable medium of claim 19, wherein said identifying step includes 
performing a multi-stage analysis of said status data. 

21 . The computer-readable medium of claim 20, wherein said multi-stage analysis 
includes performing a discrimination analysis on said status data. 
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22. The computer-readable medium of claim 2 1 , wherein the discrimination analysis 
includes positive filtering. 

23. The computer-readable medium of claim 2 1 , wherein the discrimination analysis 
includes negative filtering. 

5 24. The computer-readable medium of claim 2 1 , wherein the discrimination analysis 
includes filtering followed by an analysis of post-filtering residue. 

25. The computer-readable medium of claim 20, wherem said multi-stage analysis 

includes analysis at the probe and analysis at a secure operations center configured 
to receive data firom said probe. 

10 26. The computer-readable medium of claim 19, wherein said identifying step includes 
aggregating and synthesizing said status data at the probe. 

27. The computer-readable medium of claim 26, wherein said identifying step includes 
cross-correlating data across said monitored components. 

28. The computer-readable medium of claim 26, wherein said identifying step includes 
1 5 analyzing the frequency of occurrence of said events. 

29. The computer-readable medium of claim 19, further comprising after said step (c), 
performing further computer-based analysis at a secure operations center config- 
ured to receive data from said probe. 

30. The computer-readable mediimi of claim 29, wherein said computer-based analysis 
20 includes aggregating, synthesizing, and presenting alerts on an ensemble basis. 

31 . The computer-readable medium of claim 29, wherein said identifying step includes 
cross-coirelating data across said monitored components. 
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32. The computer-readable medium of claim 29, wherein said identifying step includes 
analyzing the frequency of occurrence of said events. 

33. The computer-readable medium of claim 29, wherein said computer-based analysis 
includes cross-probe correlation. 

S 34. The computer-readable medium of claim 19, further comprising instantaneously 
self-tuning said probe based on previously collected status data. 

35. The computer-readable medium of claim 19, wherein said dynamic modifying step 
includes consideration of non-real-time infomiation from ongoing security research 
efforts. 

10 36. The computer-readable medium of claim 19, wherein said receiving feedback step 
occurs in substantially real time. 

37. A security monitoring system for a computer network, comprising 

a) a plurality of sensors for monitoring components of said network; 

b) at least one secure operations center configured to receive and analyze 
1 5 potentially security-related event data from at least one probe; and 

c) at least one probe, wherein said probe is configured to 

(1) collect status data from at least one sensor monitoring at least one 
component of said network; 

(2) identify potentially security-related events pertaining to said net- 
20 work by analyzing said status data; 

(3) transmit information about said identified events to an analyst 
associated with said secure operations center; 

(4) receive feedback based on empirically-derived information reflect- 
ing operation of said security monitoring system in a maimer cus- 

25 tomized to said network; and 
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(5) dynamically modify an analysis capability of said probe during 
operation thereof based on said received feedback in a manner 
customized to said network. 

38. The security monitoring system of claim 37, wherein said probe is configured to 
identify potentially security-related events by performing a discrimination analysis 
on said status data. 

39. The security monitoring system of claim 38, wherein said probe is configured to 
identify potentially security-related events by performing a positive filter discrimi- 
nation analysis on said status data. 

40. The security monitoring system of claim 38, wherein said probe is configured to 
identify potentially security-related events by performing a negative filter discrimi- 
nation analysis on said status data. 

41 . The security monitoring system of claim 37, wherein said probe and said seciu^ 
operations center are configured to identify potentially security-related events by 
performing a multi-stage analysis of said status data. 

42. The security monitoring system of claim 41 , wherein said multi-stage analysis 
includes analysis at the probe and analysis at said secure operations center. 

43. The security monitoring system of claim 37, wherein said secure operations center 
is configured to identify potentially security-related events by performing a 
computer-based analysis of said potentially security-related event data received 
firom said probe. 

44. The security monitoring system of claim 43, wherein said computer-based analysis 
is configured to correlate data from different probes. 
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FIG. 1 - Architectural Diagram 
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FIG. 3 - Gateway System Overview 
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FIG. 4 - SOCRATES System Overview 
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FIG. 5 - Incident Handling 
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FIG. 6 - Escalation 
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FIG. 7 - CaU HandUng 
Procedure (Existing Ticket) 
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FIG. 8 - CaU Handling Procedure 
(Customer Cold Call) 
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FIG. 9 - Problem Workflow 
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